Amazon Kinesis StreamとAmazon Kinesis FirehoseのAPIを比較する #reinvent

AWS re:Invent 2015

#AWS

#Amazon Data Firehose

quiver

2015.10.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:invent 2015 では Amazon Kinesis の兄弟サービス Amazon Kinesis Firehose が発表されました。

本稿では、新旧 Kinesis の API を比較したいと思います。

サービス名

旧 Kinesis は Kinesis Streams というサービス名にリブランディング?され、新 Kinesis は Kinesis Firehose というサービス名で発表されています。

API としては Kinesis Streams は kinesis、新 Kinesis は firehose と名前空間が切られています。この違いは管理画面の URL でも確認可能です。

ストリーム操作

API	Kinesis Streams	Kinesis Firehose
ストリーム一覧を表示	list-streams	list-delivery-streams
ストリームを作成	create-stream	create-delivery-stream
ストリームを作成	delete-stream	delete-delivery-stream
ストリームを表示	describe-stream	describe-delivery-stream
ログ保存期間の増加	increase-stream-retention-period	存在しない
ログ保存期間の減少	decrease-stream-retention-period	存在しない

stream と delivery-stream という名前の違いがあります。

ログ保存期間(retention period)に関し、 Kinesis Firehose は24時間固定で、Kinesis Streams は24時間から7日までの間で変更可能です。Kinesis Firehose が発表されるまでは Kinesis Stream も24時間固定でした。

タグ操作

API	Kinesis Streams	Kinesis Firehose
タグ追加	add-tags-to-stream	存在しない
タグ削除	remove-tags-from-stream	存在しない
タグ一覧	list-tags-for-stream	存在しない

Kinesis Firehose のストリームはタグ操作に対応していません。

こちらはほどなく機能追加されるのではないでしょうか。

シャードの操作

API	Kinesis Streams	Kinesis Firehose
シャードの分割	split-shard	存在しない
シャードの結合	merge-shards	存在しない

Kinesis Streams ではシャードごとの処理能力が明確に定義され、メトリクスをモニタリングしながら、データ量に応じてリシャーディング処理が必要でした。

Kinesis Firehose では AWS がこのめんどくさいリシャード処理をいい感じ運用してくれます(Keynote では "elastically scale" とおなじみの表現が使われていましたね)。Kinesis Firehose の製品ページから引用します。

The service takes care of stream management, including all the scaling, sharding, and monitoring, needed to continuously load the data to destinations at the intervals you specify.

レコード追加

API	Kinesis Streams	Kinesis Firehose
単一レコード追加	put-record	同じ
複数レコード追加	put-records	同じ

このAPIは同じです。

レコード処理

API	Kinesis Streams	Kinesis Firehose
イテレーター取得	get-shard-iterator	存在しない
レコード取得	get-records	存在しない
レコード連携先指定	存在しない	update-destination

Kinesis 系はレコードが一定期間バッファリングされ、保存期間内であれば何回でも取得可能です。

Kinesis Streams はレコード取得処理が煩雑

そのため、Kinesis Streams からレコード取得する際は

レコードの位置を取得(get-shard-iterator)
位置からN件レコードを取得(get-records)

という2段階の処理が必要でした。

また、Kinesis Streams のレコード取得は (ストリーム, シャード)単位で行われるため、リシャーディングでシャードが増減すると、アプリケーション側も増減したシャードを検知してレコード処理しなければなりません。そのため、Kinesis Client Library のようにリシャーディングと連動し、取得したレコードの処理(ビジネスロジック)に注力できるライブラリが必須でした。